2026-02-01T01:40:09Z
Q: How can I tell if my terminal supports TrueColor (24-bit color)?
A: You can run the following command to test if your terminal supports TrueColor:
awk 'BEGIN{
s="/\\/\\/\\/\\/";
for (colnum = 0; colnum<77; colnum++) {
r = 255-(colnum*255/76);
g = (colnum*510/76);
b = (colnum*255/76);
if (g>255) g = 510-g;
printf "\033[48;2;%d;%d;%dm", r,g,b;
printf "\033[38;2;%d;%d;%dm", 255-r,255-g,255-b;
printf "%s\033[0m", substr(s,(colnum%4)+1,1);
}
printf "\n";
}'The above script is from:
If your terminal hardware supports TrueColor, you should see a smooth gradient of colors from red to green to blue. If you see a limited number of colors or a blocky gradient, your terminal may not support true color.
You can also check the COLORTERM environment variable by typing:
echo $COLORTERM
truecolorIf the output is “truecolor” or “24bit”, your terminal hardware supports TrueColor. For most situations, this is sufficient to confirm TrueColor support, and further checks are not generally not beneficial or necessary.
Even if your terminal hardware supports TrueColor, your terminfo may not. Keep in mind that the number of colors set in terminfo only affects applications that choose to use it. A terminfo setting of 256 colors does not limit which of the 16M colors an NCurses application can display, but only the number of color pairs that can be displayed simultaneously.
Note: The remainder of this section takes a deep dive into a rabbit hole that most users will not benefit from exploring. If your terminal hardware supports TrueColor, and the COLORTERM variable indicates TrueColor support, you needn’t continue reading.
You can check your terminfo color capabilities by typing:
tput colorsIf the output is 16777216, your terminfo supports TrueColor.
Even if your hardware supports TrueColor, but the above indicators report only 256 colors or less, you can set the TERM variable to a value that supports Truecolor. For example, you can set the TERM variable to “xterm-direct” by adding the following line to your ~/.bashrc or ~/.zshrc file:
export TERM=xterm-directThe caveat is that xterm-direct and other terminfo files may come with limitations. For example, I have found that xterm-direct, lacks the “ccc” (Can-Change-Color) flag. This flag is advisory only for applications that choose to use it.
I use one of::
export TERM=xterm-ghostty
export TERM=xterm-kitty
export TERM=xterm-bwYou can create your own custom terminfo entry using infocmp and tic, but beware. Terminfo is a complex and sometimes arcane system, and not all applications will work properly with custom entries.
Both the Ghostty and Kitty terminfo files set Number of Colors to 256, and that is perfectly understandable considering that:
If you are determined to have more than 256 colors at one time, you can get around this issue by using infocmp to create a custom terminfo entry that specifies higher color capabilities. Here is an example of how to do this, but it is not recommended.
infocmp xterm-256color > xterm-myterm.tiAdd or modify the following lines in xterm-myterm.ti
ccc, colors#0x1000000, pairs#0x10000Once you have finished editing xterm-myterm.ti, compile it using tic:
tic xterm-myterm.tiAnd, set your TERM environment variable to your new terminfo entry:
export TERM=xterm-mytermYou can also refer to this helpful list of terminals and their color support:
Q: I am trying to view a program file in view, but it is displaying ANSI escape codes.
A: No worries. I ran into the same problem. View is not recognizing the ANSI escape codes. Taking a closer look at the file, I can see the “intro” characters repeated, “0x1b[0x1b[”. This happens when the output file of a colorizer or highlighter is processed a second time by a colorizer or highlighter. It tries to put ANSI escape codes around the existing ANSI escape codes, resulting in the “0x1b[0x1b[” sequence, which View can’t interpret.
Out of curiosity, I ran the same file through less, which produced the same results as C-Menu View. In the world of pagers, less is the gold-standard, and apparently they chose not to address this issue. Therefore, it seems the best solution is to avoid double exposure. If you have a file that has been colorized or highlighted, don’t run it through another colorizer or highlighter. Use C-Menu’s stripansi to remove the ANSI escape codes before re-colorizing or re-highlighting. This works for C-Menu View as well as less.
Below, I have included a screenshot using less.
Q: CKeys show alt-keys correctly. How can I fix this?
A: CKeys relies on the terminfo database to interpret key codes. If your terminal emulator is not set to a terminfo entry that matches its capabilities, CKeys may not recognize certain keys correctly.
To fix this, ensure that your TERM environment variable is set to a value that accurately reflects your terminal emulator. You can check your current TERM setting by typing:
echo $TERMIf it is set to a generic value like “xterm” or “vt100”, consider changing it to a more specific entry that matches your terminal emulator, such as “xterm-256color”, or “xterm-ghostty”. I have found that these terminfos produce the results I expect, while xterm-kitty produces different results. That doesn’t mean that xterm-kitty is wrong, because it is simply interpreting certain alt-key codes differently. I am not aware of any terminal emulators that don’t support xterm-256color.
I started to write some code to save and load alt-keys from a file, but that is problematic in C. It is customary to use switch statements to interpret key codes, but switch statements require constant expressions, and file input is not a constant expression. That’s not a limitation in Rust, which has more flexible pattern matching. When you start writing code in Rust, you start thinking in Rust, and C starts to feel like driving your Grandmother’s Oldsmobile at Le Mans.
You can change the TERM variable by adding the following line to your ~/.bashrc or ~/.z.
zshrc file:
export TERM=xterm-256colorAfter updating your TERM variable, restart your terminal session and run CKeys again. It should now recognize the keys correctly.
Q: When I try to view a document that contains line-drawing characters, View displays question marks instead of the line-drawing characters. How can I fix this?
A: The file may contain characters above 0x80, which can’t be translated by View’s character translators. If the offending characters CP-437 line drawing characters, you can convert the file to UTF-8 encoding using a tool like ‘iconv’ or ‘recode’. For example, you can use the following command:
iconv -f CP437 -t UTF-8 inputfile.txt -o outputfile.txtThe images below show, before, on the left, and after, on the right, using iconv.
As an interesting note, this also works for “less”, which displays the ordinal values of the CP437 characters. “less” could have automaticaly recognized and converted the CP437 characters, but the developer chose not to, and it was probably a wise decision. If you are modernizing your document archives, you shouldn’t propagate CP437 encoded files into the future. It’s far too easy to convert them to UTF-8. The “less” rendition was useful for me, because I have been programming long enough to recognize the ordinal numbers as CP437 line-drawing characters. That may not be true for someone born after 1980.
I am certainly not being critical of “less”, nor am I suggesting that C-Menu’s View is superior. We both ran into the same issue, and chose to reveal the problem with the underlying character encoding, rather than masking it.
Below are the “less” screenshots before conversion to UTF-8 and after.
Once converted to UTF-8, less displays the line-drawing characters just as View does. The converted files for C-Menu View and less were the same size when displayed, but I had to shrink the converted less screenshot on the right to fit both before and after screenshots side by side.
